Over the past years, various telecommunication networks have developed that are based on different communication standards or protocols (e.g., CDMA, UMTS, GSM, etc.). Recently, the concept of utilizing relay nodes to provide another layer of access points for communication with base stations (or base nodes) is gaining some attention. Such relay nodes are located at fixed points within the networks. The present disclosure is directed to relay nodes, regardless of the communication standard or protocol that is deployed in the telecommunications network. However, for ease of understanding, the present disclosure is being described with reference to a particular type of network.
The 3rd Generation Partnership Project (3GPP) has characterized a Long Term Evolution (LTE) upgrade for mobile networks. Within the LTE specification, the radio access interface and network is typically known as the Evolved UMTS Terrestrial Radio Access (E-UTRA). E-UTRA is sometimes also referred to as E-UTRAN. For further information on the E-UTRA standard and an overall description, reference is made to 3GPP Technical Specification (TS) 36.300 V10.5.0 (2011-09) (Release 10), which is incorporated herein by reference.
E-UTRA is intended to replace UMTS, HSDPA and HSUPA technologies and is different and incompatible with W-CDMA. This standard provides higher data rates, lower latency and is designed for packet data. This will allow network operators to provide voice, high-speed interactive applications, large data transfer and feature-rich IPTV with mobility. E-UTRA (and LTE) has been designed to be a single evolution for the current GSM/EDGE, UMTS/HSPA, CDMA2000/EV-DO and TD-SCDMA radio interfaces.
With reference to FIG. 1, there is illustrated the typical E-UTRA network architecture and a portion of the evolved packet core (EPC). The E-UTRA network includes the deployment of evolved Node Bs (eNodeB or eNB). eNodeBs perform functions similar to the separate NodeBs and radio network controllers (RNCs) used in the UTRAN, while the NodeB is a term used in UMTS networks as an entity that is functionally equivalent to base transceiver stations (BTS) used in GSM.
As shown in FIG. 1, a current architecture and system 100 includes a plurality of eNodeBs (i.e., access points) 102 and a plurality of mobile management entity/service gateways (MME/S-GW) 104. As will be appreciated, the MME/S-GWs 104 form part of the EPC, and the MME and S-GW entities may be integrated or separate. The MME entity is responsible for signaling (control plane) while the S-GW entity is responsible for data (user or data plane). eNodeBs 102 may be interconnected with each other through an X2 interface, while each eNodeB 102 is connected with one or more MME/S-GWs 104 through an S1 interface. The system 100 includes a number of wireless terminal communication devices (referred to as user equipment or UEs) 110, which may include wireless mobile phones, PDAs, tables, computers, etc. As shown, UE 110a is in wireless communication with one eNodeB 102, while UEs 110b, 110c are in wireless communication with another eNodeB 102.
Though not shown, the EPC includes additional entities or devices, including a PDN gateway (P-GW), which is connected to an external packet data network (e.g., the Internet). The P-GW entity is also responsible for managing the data stream (known as the user plane or data plane). Though only three eNodeBs 102 and two MME/S-GWs 104 are shown, more or less may make up the system 100.
Within the E-UTRA (Release 10), there is provided a “relay node” (RN) concept which supports the inclusion of relay nodes (RNs) wirelessly connected to the eNodeBs 102. FIG. 2 illustrates the E-UTRA system with an RN 106 and a donor eNodeB (DeNodeB) 108. In this network configuration, the UE 110a is in wireless communication with one eNodeB 102, while UEs 110b, 110c are in wireless communication with the RN 106. Those eNodeBs that are wirelessly connected to a relay node (RN) are referred to as “donor” eNodeBs (DeNodeB). The interface between the RN 106 and a DeNodeB 108 is referred to a Un interface. As will be appreciated, the RN 106 functions to terminate the radio protocols of the E-UTRA air interface (with the UEs 110b, 110c) and provide/terminate the S1 and X2 interfaces. Though only one RN 106 and one DeNodeB 108 are shown, the system 100 may include multiple RNs and DeNodeBs. For additional technical information on the E-UTRA and E-UTRAN, reference is made to the technical specification “3GPP TS 36.300 V10.5.0 (2011-09)”.
However, these RNs were targeted and functionally limited as stationary—which means the relay nodes were designed in the system to be fixed (i.e., not mobile). As such an RN's DeNodeB was not expected to change during RN operation.
It has been determined that in high speed mobile scenarios, e.g., when the UEs are moving relatively fast, such as aboard a moving passenger train, it is extremely difficult to utilize the typical eNodeB network configuration along the UEs' path. Several problems exist in such a high speed train scenario —large number of UEs concentrated in a small space (causing high traffic load), high speed (causing many hand offs per second and performance degradation due to high Doppler shift of the radio signal), and high penetration loss of the radio signal through well-shielded train cars (carriages) leading to poor coverage within the train.
With reference to FIG. 3A, there is shown a typical diagrammatic system 300 into which the present disclosure may be incorporated and advantageous. The system 300 includes a moving vehicle (or object) 302 depicted traveling from left to right along a roadway or track (or path) 304. Also shown in system 300 are two eNodeBs 102a, 102b (eNB1, eNB2) spaced and positioned along the path 304 which are configured and operable to provide wireless communication functionality and wireless communication links with one or more wireless access devices 306 (only one shown) located aboard the moving vehicle 302. As shown, each eNodeB 102a, 102b has a predetermined coverage area depicted in FIG. 3A with dotted lines. As will be appreciated, the wireless access device 306 is affixed to the moving vehicle 302.
In the example shown in FIG. 3A, the moving vehicle is a high-speed train shown with three passenger cars or carriages 310. Now referring to FIG. 3B, there is shown a silhouette of one of the passenger carriages 310 showing the wireless access device 306, which includes an antenna 307a and antenna 307b. Also shown in dotted lines is the approximate wireless communication coverage area within the passenger carriage 310. It will be understood that each carriage 310 may have one or more access devices 306, and the number of access devices 306 may be fewer, equal to or greater than the number of passenger carriages 310 (depending on power, coverage area, etc.).
Within the passenger carriage 310 of FIG. 3B there are shown a plurality of wireless mobile devices 312 configured and operable for wirelessly communicating with the access device(s) 306. The wireless mobile devices 312 are referred to as UEs (user equipment), and may be the same or similar to the UES 110. These UEs may be mobile phones, smartphones, tablets, wireless computers, etc., and may be any device having wireless communications capabilities.
The inventor has determined that due to the high traffic load, fast handoff and high penetration loss requirements in such a high speed mobile scenario, simply utilizing a high number of eNodeBs along the path is inadequate (and relatively expensive). Another potential solution may include using a radio frequency RF repeater with the land-based eNodeBs. In this solution, though coverage within the vehicle can be improved by amplifying the RF signal, and even Doppler shift problems may be reduced with very sophisticated circuitry, these issues can be compensated for only partially. For example, since the RF repeater only amplifies, filters and then retransmits the received signal, it also amplifies and retransmits any noise received from the environment. In addition, the internal circuitry of the RF repeater adds additional noise to the desired signal. This limits the signal-to-noise ratio that can be achieved within the moving vehicle by using a simple RF repeater, thus limiting the improvement in coverage within the vehicle.
Another potential solution is use of a satellite link for backhaul. This may solve some of the aforementioned problems, but limited bandwidth and long transmission delay of a satellite link will likely create a bottleneck for a large railway with many UEs (which may be prone to consuming more data on a train, than in another type of vehicle). Another problematic issue with a satellite-based relay solution is its vulnerability to coverage obstructions from terrain and man-made clutter (e.g., hills, mountains, tunnels, buildings, etc.)
The inventor has determined, and conceived, that utilization of a “mobile” relay node installed on the train may constitute a potential solution. UEs located within the train would appear relatively stationary relative to the relay node, or at most moving at pedestrian speed as users move through the carriage. As it is not expected that such UEs would need to be handed off to eNodeBs providing coverage outside of the train, until the train stops at a station, no high speed handoffs for these UEs would be required. The only potential handoff of the UEs would be between one relay node and another relay node providing coverage within a carriage, or in two different carriages. Thus, the UEs involved would be very slow moving relative to the RN during the execution of such a handoff.
However, reliance on the currently described RNs (as described in the current Release 10 LTE standard) is not a viable solution. This is because the current RNs are designed to be fixed/stationary (i.e., do not support handoff of the RN from one donor eNodeB to another). Thus continuous service would not be possible with the current RN as the train moved from the coverage of one donor eNodeB to another donor eNodeB along the path.
For mobile UEs, the concept of home eNodeBs and home MME/S-GW is introduced (though not shown specifically in FIG. 1).
The current 3GPP standard (Release 10) introduces the relay node (RN) concept. Herein, we also introduce the terms “RN_UE” and “RN_Cell” to logically and/or physically describe or illustrate various functionality within the network (and to describe various concepts). In particular, the term “RN_UE” is used to denote that logical portion (device/entity) of an RN that appears as a UE (downstream) to a DeNodeB, while the term “RN_Cell” is used to denote that logical portion (device/entity) of the RN that appears as a cell (upstream) to the UEs.
Several problems arise when attempting to reuse the fixed RNs of Release 10 standard to provide support for a “mobile” RN (mRN). First, an RN_UE's S-GW/P-GW is a logical entity co-located within the serving DeNodeB in Rel. 10. Changing the RN_UE's serving DeNodeB requires an RN restart process involving at least reconfiguring the RN_UE's P-GW, IP address, and OAM. Second, the current RN_Cell1 is seen as a cell of the DeNodeB by the EPC. Because the RN_Cell's CGI (Global Cell Id) is associated with the serving eNodeB (i.e., shares the same Global eNodeB ID with the DeNodeB), changing the RN_UE's serving DeNodeB would require changing the RN_Cell's ECGI. Also, the configuration and setup of the RN_Cell1 is performed via OAM, and the accompanying delay resulting from changing the DeNodeB and the configuration of RN may be significant and prevent reliable hand-offs.
Accordingly, there is needed a new “mobile” RN and functionality for use in a wireless network architecture which can support many UEs and engage in fast hand-offs between itself and source and destination serving eNodeBs.